-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Describe the process of writing integration tests for GDScript #4842
Conversation
|
||
./bin/<godot_binary> --gdscript-generate-tests godot-source/modules/gdscript/tests/scripts | ||
|
||
4. Run GDScript tests with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the not to check if the *.out
files are expected should come before this step. If you generate the outputs and immediately run the test, it will always pass.
It should be clear also that if generating change other tests that you didn't add, you should revert it back and not commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if I understand correctly. Is it possible to run tests for new scripts that don't have *.out
files generated for them yet? Not sure what would be the point of that, since there will be nothing to compare the output against.
I agree that it can be clarified that those generated out
files which fail should not be committed, but a regression should reported (yet this likely won't be an issue, since regressions are going to be caught early at CI checks stages). This is also not a big deal for someone who participates in implementing GDScript language itself.
But current version does tell:
Make sure the output does have the expected values before submitting a pull request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is that, the process describes how to write new tests, not updating existing ones. If you believe it's beneficial to describe those processes separately, then it may be worth it. But I'm afraid this could potentially make the documentation more confusing.
Calinou went through those steps successfully while making godotengine/godot#48029, for instance. If someone is going to have a problem, the documentation could be further clarified I guess.
That said, not sure what kind of changes to make without breaking the currently described workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general looks good to me, apart for that small comment. |
Thanks! |
See godotengine/godot#47701.
Closes godotengine/godot-proposals#1429.